When 5.5 was rolled out, it contained a proprietary threading model that was written in-house to allow for maximum cross-platform capabilities. Now, with 6.0, we have extended our thread manager to allow you to do everything (and more!) that the OS thread manager would allow, all while keeping the effects fully cross-platform.
The features that have not changed will not be discussed here -- only the features that are new to RB 6.0.
First, some background. Whether you know it or not, all applications are threaded. Every application has at least one thread -- the main thread. In RB, we do not give you access to the main thread because it allows for you to do some very wrong things (such as killing the main thread). However, every other thread object in your application is accessible and can have its various properties changed.
Threads are managed by something called the "thread scheduler". Its task is to ensure that every thread gets a fair chance to run for as long as its priority allows. So basically, the scheduler makes sure that no thread is completely starved of resources. How the scheduler actually works is undefined from the RB-user's point of view and is subject to change at any point in time.
When the scheduler decides its time for another thread to execute it will halt the currently executing thread and start another thread running which is called a context switch. How long the thread runs for is called the time slice for the thread.
Thread.Priority as Integer -- This property allows you to get and set the relative priority of the thread. You may be asking, relative to what? Relative to every other thread in your application. The main thread has a priority of 5, and each new thread has a default priority of 5 as well. So that means, just creating new threads and running your application will behave as it always has. Each thread has an equal amount of time to share with the processor. However, if you make one of your threads have a priority of 10, then it will get twice as many time slices as the threads whose priority is still 5. If you make a thread have a priority of 1, then it will get 1/5 of the time slices that the other threads have. The lowest priority is 1, and the upper bound is 2^31-1, tho I would certainly not suggest you do that since you will certainly starve all other threads! Keep in mind that because thread priority is relative, raising all thread priorities will do _nothing_. If every thread has the same priority, then every thread will run for the same amount of time. The Thread class has three constants to describe priorities that can be used as "best guesses". There's LowestPriority = 1, NormalPriority = 5, and HighPriority = 10. You do not have to use the constants, they are only there for code readability.
Thread.State as Integer (read-only) -- This property allows you to query the state of the thread. Threads can be in one of four states. State 0 is "running", meaning that the thread is able to execute or is currently executing. State 1 is "waiting", which means that the thread has been blocked by a call to Signal or Enter on one of the locking mechanisms. State 2 is "suspended", meaning that you made a call to Thread.Suspend to cause the thread to not execute. And finally, state 3 is "sleeping", which means that you have put the thread to sleep with a call to Thread.Sleep. Each of these states have a constant on the thread class (Running, Waiting, Suspended and Sleeping) so you don't need to bother with the magic numbers. If you don't care about the fine details of what state the thread is in and you just want to know whether the thread is running or not, you can simply check Thread.State <> 0.
Thread.Suspend() -- This method allows you to put the thread in a suspended state. That means that the thread will not even be considered by the thread scheduler for execution -- it is perpetually asleep. For each time that you call Suspend, you must call Resume in order to wake the thread back up. If you call Suspend twice and Resume only once, the thread will stay in the suspended state. Calling Suspend on the currently executing thread will immediately cause a context switch.
Thread.Resume() -- This is the sister method of Suspend. It is the way in which you resume a thread executing after you have suspended it. Note that this method will also wake a sleeping thread up in addition to resuming a suspended thread. Calling Resume will not cause a context switch to happen. It simply lets the thread fall back into the normal thread scheduling routine.
Thread.Sleep( milliseconds as Integer, wakeEarly as Boolean = false ) -- This method provides you with the ability to cause a thread to sleep for a certain amount of time. The time is specified in milliseconds. The amount of time for which the thread will sleep is dependant upon the second parameter. If wakeEarly is left at false, that means the thread has no chance to wake early; it will sleep for the full amount of time specified. This is helpful if you know that the thread has nothing else to do for a while. For example, you may know that the thread doesn't need to check a certain file for at least 30 seconds, so you can put the thread to sleep for the whole 30 seconds. However, if you pass true for the wakeEarly parameter, that means your thread has the opportunity to be woken up before the full time has passed. The thread will wake early if there are no other threads able to execute. This is especially helpful if your thread wants to be a "good citizen". You can tell the thread to sleep for at most X milliseconds, but if there are no other threads doing anything, then your thread can start executing again. A good place to use this technique is if you are making a video game and you want the animation threads to possibly yield some time to another thread. Since the animation thread always has something to do, it may just want to yield for no more than a few milliseconds so that it can be a good citizen and not hog all the time. If the currently executing thread is the one being put to sleep, then a context switch will be triggered. Otherwise, the thread is just marked as sleeping and the currently executing thread can continue.
App.YieldToNextThread() -- This method allows you to trigger a context switch. This will yield the currently executing thread's time slice to another thread. The next thread to run is determined by the thread scheduler, and you should note that the next thread to run may very well be the currently executing thread.
App.CurrentThread as Thread (read-only) -- This property allows you to determine which thread is currently executing. If the property is nil, that means the main thread is what is currently running. So be prepared for this property to return nil!
